1. Field of the Invention
The present invention relates to computer software, and more particularly to displaying database record organization data of IMS databases.
2. Description of the Related Art
The IMS database (IMS DB) was created in 1970 by International Business Machines Corporation (IBM) and is one of the two major parts to IBM""s IMS/ESA (Information Management System/Enterprise Systems Architecture). The second part is a data communications system (IMS Transaction Manager or IMS TM). Together, the transaction manager and the database manager create a complete online transaction processing environment providing continuous availability and data integrity. IMS/ESA runs under the MVS/ESA or OS/390 operating systems, which run on the S/390 platform.
At the heart of IMS DB are its databases and its data manipulation language, Data Language/I (DL/I). The IMS database is a hierarchical (non-relational) database. IMS databases are hierarchic collections of data, information organized in a pyramid fashion with data at each level of the hierarchy related to, and in some way dependent upon, data at the higher level of the hierarchy. DL/I calls allows a user to create and access these IMS databases.
An IMS database may include one or more data set groups. Each data set group may include one or more segments. A segment is the smallest piece of data DL/I can store. Each segment may be qualified by its hierarchical relationship to other segments in a database record. Each database record has one root segment and zero or more child segments. A xe2x80x9croot segmentxe2x80x9d is at the top of the hierarchy, and there may be only one root segment in a database record. All other segments (other than the one root segment) in a database record are referred to as xe2x80x9cdependent segmentsxe2x80x9d, and their existence depends on there being a root segment. A xe2x80x9cparent segmentxe2x80x9d is any segment that is defined in the database descriptor (DBD) as capable of having a dependent segment beneath it in the hierarchy. A xe2x80x9cchild segmentxe2x80x9d is any segment that is a dependent of another segment above it in the hierarchy.
Segments may be of various segment types. Those segments which share similar qualities are of the same type. For example, if the root segment of a database record represents a course, and that root segment has three child segments labeled: instructor, student, and location, those child segments may be referred to as segment types.
The root segment is referred to as a first level of the IMS database, and direct children of the root segment are referred to as a second level of the IMS database. As used herein, a second level of the IMS database may alternatively be referred to as a first level child segment, as child segments may only appear starting with the second level of the IMS database. Similarly, children of the children of the root segment (i.e., grandchildren of the root segment) are referred to as a third level of the IMS database, or alternatively, second level child segments. The level of each subsequent generation of children may be determined by incremented the previous level by one (e.g., a fourth level of the IMS database is equivalent to a third level child segment).
An IMS database includes a maximum of ten data set groups into which segments of an IMS database may be written. Each segment type may only be assigned to one data set group. When IMS databases are created, definitions of which data set group each segment type is to be written to are specified. In some cases, an IMS database may also be divided into partitions, in addition to being distributed across data set groups. A database record is made up of a root segment and child segments. As an IMS database is used, segments and database records are added, modified and deleted. Over time, the child segments of a database record may become scattered across different blocks within a data set group, resulting in slower access times and longer latencies than would occur if the child segments were closer together or contiguous. Reorganizing the location of the various segments of an IMS database such that segments of database records are closer together results in faster access times and shorter latencies.
The need to periodically reorganize an IMS database stems from the dynamic nature of insertions and deletions of segments in an IMS database. In general, as new child segments are added to an IMS database hierarchy, the segments may be added to blocks depending on space availability. As a result, related segments (i.e., segments belonging to the same database record) may be stored in different blocks, possibly non-contiguous blocks. Due to this scattering of related segments across different blocks within a data set group, over time, the IMS database becomes fragmented. Fragmentation exists in both segment to segment access and distribution of free space within the blocks. As a result, access of a database record may require reading a number of non-contiguous blocks, which results in lengthier access times. One method of reducing access times is to reorganize the IMS database in order to more closely position segments belonging to the same database record and to re-distribute areas of free space for later insertions.
The current technique of timing reorganizations of IMS databases (i.e., deciding when to initiate a reorganization) is typically based on either a temporal trigger (e.g., daily, weekly, monthly, quarterly), a volume trigger (e.g., after 1,000 transactions), or a shortage of free space available to hold new database data. Failure to detect or anticipate a shortage of free space may cause the database and supporting applications to suffer an xe2x80x98outagexe2x80x99 and therefore be unable to perform important business tasks. Failure of the applications to perform the business tasks may result in significant lost revenue and business opportunities. It is desirable to have a method of analyzing database record organization characteristics that may be able to recognize that the amount and distribution of free space available in an IMS database (or even a selected block or data set group sub-set of an IMS database) is approaching a threshold. Reaching this threshold would indicate either a benefit from reorganizing the IMS database or the potential for a database xe2x80x98outagexe2x80x99 due to lack of free space.
A visual or graphical representation of the database record organization may allow an xe2x80x98outagexe2x80x99 to be avoided. A visual or graphical representation of the database record organization characteristics of an IMS database may also be helpful for a DBA (database administrator) or other knowledgeable user in adjusting database parameters that control how insertions, modifications, and deletions of database records within the database are managed. It is desirable for a DBA or other knowledgeable user to have access to the graphical representation of the database record organization characteristics of the IMS database remotely (i.e., without requiring the user to manually connect/login to the IMS database), for purposes of analysis. For at least the foregoing reasons, there is a need for an improved system and method for displaying the database record organization characteristics of databases, such as IMS databases.
The present invention provides various embodiments of an improved method and system for displaying database record organization characteristics of IMS databases. In one embodiment, the method involves receiving information associated with a plurality of database records from a database (e.g., an IMS database). The information associated with the plurality of database records may comprise information associated with ranges of database records within the database. The information associated with the plurality of database records may be transmitted to a client computer system, such as a Microsoft Windows based computer system, for display in a graphical user interface. The transmission may be accomplished through various conventional means (e.g., ftp (File Transfer Protocol) or TCP/IP (Transmission Control Protocol/Internet Protocol)). The transmission may be initiated from either the mainframe computer system or from the client computer system.
The information associated with the plurality of database records may be processed to generate database information. The database information may comprise information concerning database record organization characteristics (e.g., an amount (e.g., a percentage or a range of percentages) of reorganization required for the database records). Calculations of view ratios may be made, based upon the database information. A working storage array may be built to consolidate the information associated with the plurality of database records. A plurality of view envelopes may be constructed, based upon data in the working storage array. The size of the plurality of view envelopes constructed may be based upon a first view ratio.
The plurality of view envelopes may be graphically displayed on a display. A legend may also be displayed on the display, for purposes of explaining the various markings and/or colors within each view envelope. Database record (DBR) key values may be displayed, to indicate the DBRs corresponding to the view envelopes displayed.
User input may be received. The user input may specify a sub-set of the plurality of view envelopes to be graphically displayed. The user input may be to request xe2x80x9cinspectionxe2x80x9d of a selected view envelope. Inspecting a view envelope is a way to see more detailed information about the database record organization characteristics represented by a single view envelope (e.g., in need of reorganization; recently reorganized; organized). The user input may be to request xe2x80x9cidentificationxe2x80x9d of a selected view envelope. Identifying a view envelope is a way to display identifying information about the view envelope (e.g., Low Key, High Key, Reorganization needed (i.e., the count of DBRs classified as needing reorganization), and database record (DBR) reorganized (i.e., the count of DBRs previously reorganized)).
An xe2x80x9cinspection/identificationxe2x80x9d (i.e., an inspection followed by an identification) of a collapsed DBR key may be a way to display identifying information about the DBR (e.g., Key, Blocks Used, Estimated Blocks needed, Mark for reorganization, and Submit for reorganization). A xe2x80x9cdetailed inspectionxe2x80x9d of an inspected collapsed DBR key may be a way to display identifying information about the blocks used by a DBR key (e.g., view envelopes indicating xe2x80x9c% of block usedxe2x80x9d for each block used by the DBR).
The concept of xe2x80x9cmarkingxe2x80x9d, xe2x80x9cunmarkingxe2x80x9d, and xe2x80x9csubmittingxe2x80x9d a DBR may be extended to all DBRs in the database, through any of various methods (e.g., a menu item with the choices: (1) submit all DBR (database records) for reorganization; (2) submit all marked DBR for reorganization; (3) unmark all DBRs; (4) mark all DBRs). Upon submission, the keys associated with the marked DBRs may be transmitted through various conventional means from the client computer system to the mainframe computer system. After completion of the DBR reorganizations requested, the mainframe computer system may transmit the updated database record organization characteristics to the client computer system. The client computer system may display xe2x80x9cbeforexe2x80x9d and xe2x80x9cafterxe2x80x9d database record organization characteristics, as appropriate.